@syrusakbary https://github.com/wasmerio/wasmer/actions/runs/16106520659/job/45444368736?pr=5621#step:4:257 It seems these tests fail caused by CI permission?

📝 Documentation updates detected!

New suggestion: Document wasi-common feature for WASIX library

Hey @hardfist,
I see you introduced the wasi-common feature, but it doesn't do any code restrictions at all that would decrease the code size.
Ideally, we would see some systemcalls being restricted/not added on the WASI lib.rs file, which would let the compiler optimize the not-used code away.

Also, You made the wasi-common feature being xor'ed with js or sys which doesn't make that much sense. wasi-common should/could be used with either js or sysm

Hey @hardfist, thank you for this contribution!

From what I can tell, the change adds a new feature, which disables some of the dependencies. I have doubts about the exact set of dependencies enabled, though. For example, disabling the host networking feature isn't 100% compatible with wasip1, as with wasip1, you do get networking, just not the ability to open new sockets.

Since the set of features enabled in the wasi-common feature is not something that aligns 100% with wasip1, I wonder if it'd be better to just enable just these features in your own crate that depends on wasmer-wasix? I understand this is not possible today because we refuse to compile without exactly one of the sys or js features, so my suggestion is:

• we revert this change
• instead, we add in a new feature, named sys-minimal, which will be equivalent to "enable native stuff such as state::handles::globals, but nothing else"
• sys and sys-minimal can both be active at the same time, since they don't clash in any way, but if at least one is enabled, js must be disabled. Also, at least one of js or (sys/sys-minimal) must be enabled for the crate to compile.
  • This is, BTW, another issue with the current implementation; you can, for example, have wasi-common and js active at the same time and not trigger the compile errors
• client crates can then enable sys-minimal and cherry pick any other features they need, leaving out unused ones to avoid code bloat.

Would this solve your usecase, @hardfist?

The wasi-common semantic I want is actually the same as @Arshia001 's suggestion of sys-minimal(I use wasi-common just because wasmtime use this naming 🤣), so @Arshia001 your suggestion would be perfect for my case.

I see you introduced the wasi-common feature, but it doesn't do any code restrictions at all that would decrease the code size.

I think it can reduce the binary size cause it doesn't enforce all features sys and js do, so consumer can pick minimal feature

Cool! Do you want to make the implementation?

Cool! Do you want to make the implementation?

yeah, I can give it a second try

LGTM now!

@Arshia001 I also notice that some of wasmer's dependency is not necessary for our case like wat and wonder whether it could be feature gated too like wasix, if so I can continue improve in following PR

@Arshia001 it seems these failing tests is not related to the change?

@hardfist I'm quite sure we already have a wat feature in wasmer. I remember it having a sizable impact on binary size.

The integration tests are flaky, and hence not marked as required. Merging this in. Thanks again!

@Arshia001 sorry to bother, when will wasmer release next version?

I don't have an exact time, but 6.1 is coming soon, probably as soon as the current work on dynamic linking is done, which is very close to the finish line.